Securing MongoDB

Follow these guidelines for securing MongoDB:

  • Enable Access Control and Enforce Authentication

    • Enable access control and specify the authentication mechanism. You can use MongoDB's SCRAM or x.509 authentication mechanism or integrate with your existing Kerberos/LDAP infrastructure. Authentication mechanism should ensure that all clients and servers provide valid credentials before they can connect to the system.

  • Configure Role-Based Access Control

    • Create an administrator role first and then create other user roles. Create a unique MongoDB role for each person/application that accesses the system.

    • Provide access to the users based on the principle of least privilege. That is, provide minimum level of access or permission to roles, then create users and assign only the roles they need to perform their operations. A user can be a person or a client application.

  • Encrypt Communication (TLS/SSL)

    • Configure MongoDB to use TLS/SSL for all incoming and outgoing connections. Use TLS/SSL to encrypt communication between mongoDB and Mongos components of a MongoDB deployment as well as between all applications and MongoDB.

    • Starting in version 4.0, MongoDB uses the native TLS/SSL OS libraries.

  • TLS (>= 1.2) connection to MongoDB is preferred over non-TLS connection.

  • Encrypt and Protect Data

    • Encrypting data at rest. Encrypt the data where it is stored. At rest encryption is not available for MongoDB Community Edition; it requires MongoDB Enterprise or MongoDB Atlas.

      • Starting with MongoDB Enterprise 3.2, you can encrypt data in the storage layer with the WiredTiger storage engine's native Encryption at Rest.

      • If you are not using WiredTiger's encryption at rest, MongoDB data should be encrypted on each host using file-system, device, or physical encryption (e.g. dm-crypt). Protect MongoDB data using file-system permissions. MongoDB data includes data files, configuration files, auditing logs, and key files.

      • Collect logs and store the logs in a secure location. These logs contain DB authentication attempts including source IP address.

    • Encrypting data in transit. By default, with MongoDB, all data is encrypted in transit using TLS. Even if all the connections are behind firewalls and there’s no external exposure, those internal connections still need to use TLS to reduce the risk that a breach of an environment will lead to additional database breaches.

    • Configure MongoDB to use TLS/SSL for all incoming and outgoing connections. Use TLS/SSL to encrypt communication between mongoDB and mongos components of a MongoDB deployment as well as between all applications and MongoDB.

  • Limit Network Exposure

    • Ensure that MongoDB runs in a trusted network environment and configure firewall or security groups to control inbound and outbound traffic for your MongoDB instances.

    • Disable direct SSH root access.

    • Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available.

  • Audit System Activity

    • Audit Trails: Audit trails track all changes to database configurations and administrative access. MongoDB logs may contain sensitive information depending on log verbosity. Logs are not encrypted under MongoDB's encrypted storage engine.

    • MongoDB 3.4 Enterprise includes the security.redactClientLogData setting to minimize sensitive information in logs. Enabling this feature reduces log detail, which may complicate diagnostics. For details, see the Log Redaction Manual.\

    • Server-Side Scripting: MongoDB supports JavaScript execution for operations like mapReduce, $where, $accumulator, and $function. If unused, disable server-side scripting with the --noscripting command-line option.

    • Auditing Facility: The auditing facility outputs events to the console, syslog, JSON, or BSON files. For enabling auditing in MongoDB Enterprise, see Configure Auditing.

      Audit Events and Filter

      Once enabled, the auditing system can record the following operations:

      • Schema (DDL)

      • Replica set and sharded cluster

      • Authentication and authorization

      • CRUD operations (requires auditAuthorizationSuccess set to true)

      • For details on audited actions, see Audit Event Actions, Details, and Results.

  • For information on the audit log messages, see System Event Audit Messages.

  • Input validation - NoSQL databases are still vulnerable to injection attacks, so only passing it validated known good input, use of parameterization in your application frameworks, all the good practices for passing un-trusted input to a database is required.